As should be appreciated, a virtual machine is a software construct or the like operating on a computing device or the like for the purpose of emulating a hardware system. Typically, although not necessarily, the virtual machine is an application or the like and is employed on the computing device to host a user application or the like while at the same time isolating such user application from such computing device or from other applications on such computing device. A different variation of a virtual machine may for example be written for each of a plurality of different computing devices so that any user application written for the virtual machine can be operated on any of the different computing devices. Thus, a different variation of the user application for each different computing device is not needed.
New architectures for computing devices and new software now allow a single computing device to instantiate and run a plurality of partitions, each of which can be employed to instantiate a virtual machine to in turn host an instance of an operating system upon which one or more applications may be instantiated. Typically, although not necessarily, the computing device includes a virtualization layer with a virtual machine monitor or the like that acts as an overseer application or ‘hypervisor’, where the virtualization layer oversees and/or otherwise manages supervisory aspects of each virtual machine, and acts as a possible link between each virtual machine and the world outside of such virtual machine.
Among other things, a particular virtual machine on a computing device may require access to a resource associated with the computing device. As may be appreciated, such resource may be any sort of resource that can be associated with a computing device. For example, the resource may be a storage device to store and retrieve data, and generally for any purpose that a storage device would be employed. Likewise, the resource may be any other asset such as a network, a printer, a scanner, a network drive, a virtual drive, a server, a software application, and the like. Accordingly, whatever the resource may be, the virtual machine may in fact be provided with access to services provided by such resource.
In a computing device with multiple partitions instantiated, any particular resource of the computing device may be dynamically assigned to a particular partition/virtual machine (hereinafter ‘virtual machine’ or ‘VM’) so that the particular VM can directly control such resource and service requests for the resource from other VMs on the computing device. Such particular VM, then, is in effect a host that provides resource capabilities as a resource host VM (‘VM-H’) that ‘owns’ the particular resource. Similarly, such VM-H provides resource services to another VM which is in effect a client that consumes such capabilities as a resource client VM (‘VM-C’). Thus, the VM-C and the VM-H in combination accomplish operations that require use of the particular resource.
A particular VM-C operating on a computing device typically is constructed to operate as if a real machine. That is, the particular VM-C in accessing a particular resource typically acts as if such particular resource is accessible by way of direct requests thereto. Accordingly, it may be the case that the VM-C has constructed a path or stack (hereinafter, ‘stack’) of drivers to which such requests are directed, with the expectation being that the particular resource is at the end of the stack. As has been established, however, the VM-C is not in fact a real machine and the particular resource is not in fact at the end of the stack.
Accordingly, it may be the case that the resource is emulated by the virtualization layer/virtual machine monitor as being at the end of the stack. In reality, the virtualization layer forwards a request for the resource to the VM-H that owns or has access to such resource. Alternatively, the VM-C may be endowed with enlightened capabilities in which such VM-C is aware of the virtual existence thereof, and sends requests to the particular resource by way of an ‘enlightened’ stack at the end of which is a VM (virtual machine) bus or other communications path that connects the VM-C with the VM-H that owns or has access to the resource, where the VM bus bypasses the virtualization layer. Thus, the VM-C in the enlightened mode is aware that the particular resource can be accessed by way of the VM-H, and accordingly establishes a connection with the VM-H by way of the aforementioned enlightened stack and VM bus. In such a manner, each request sent by the VM-C to the particular resource follows a direct channel to the particular resource by way of the corresponding VM-H.
As may be generally appreciated, the VM bus is a partition bus accessible by each VM. Each VM may have many channels in operation on the VM bus, each channel being operated in one of a number of different modes. Each channel may be defined by the endpoints thereof, each of which is most likely a service running within a VM. Inasmuch as each channel mode has a corresponding protocol, the VM may have many protocols in operation simultaneously. As known, each service within a VM that is associated with a channel of the VM bus is a client of the VM bus and can employ its own protocol for moving data between partitions by way of such VM bus. However, it should be clear that each service having its own VM bus protocol is cumbersome, and largely unnecessary. Thus, a need exists for a relatively simple protocol that can be employed by many services within a VM.
As may also be generally appreciated, at least some services of VMs are not performance-sensitive and not likely to take advantage of specialized modes which VM bus can be configured to use when the VM employs a particular custom protocol. In particular, services of VMs such as those that are written with user-mode code for the purpose of user interface integration are usually structured around very high-level programming constructs, such as but not limited to Component Object Model (COM) objects. Such constructs already support execution across multiple machine images using Remote Procedure Calls (RPCs). Thus, a need exists for a VM bus protocol that supports constructs such as RPCs on top of the VM bus. With such a VM bus protocol, such COM objects can be constructed with the same methods that are currently used to develop other code that involves cross-machine operation.